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Objects provide the 
useful abstraction in 
programming 
languages; views 
provide a sbnilar 
abstraction in • 
databases. Since 
databases provide for 
persistent and shared 
idata storage^ view 
(Doncepts will avoid 
problems occurring 
when persistent 
objects are to be 
shared. 
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The intention of this article is 
twofold. First of all. I show intrin- 
sic differences in the underlying 
concepts of access to persistent storage in 
databases aiid current extensions of 
object-oriented programming systems in- 
tended to incorporate, persistence.'*^ 
Since the objectives of both paiad^ms . 
are similar, I develop a connection be- ' 
. tween otject concepts in programming . 
^ languages and i/«piv concepts in database 
systems. - - .. 

Secondly, I propose an architecture that 
exploits the commonality of objects and'- 
views, and indicate research and devel- 
opment directions needed to make, the 
^ bridge viable. Such an architecture seems ; 
tb .be especially suitable for computer- ' 
aided design tasks. i a: f t 

Engineering information systems, or 
EISs, and systems for similar applications 
must provide suitable abstractions of real- 
world objects for their users and support 
long-lived trs^ s icions.^ The complexity 
of the design process and the number of 
specialized individuals needed to bring 
major projects to completion are driving 
the search for more systematized sohitions 
than those provided by the file mecha- 
nisms now in use in operational precursors 
of EISs. The issues being raised, here per- 
tain to systems with large quamitics of 
data and long lifetimes. Design task' ' at 
can be handled by single individuals are 
not likely to benefit from EIS technotogy. 

Databasn and views 

Database concepts provide indepen- 
dence of storage and us9 data formats. 
The schona describes the form of the 
database comeiits, so that a yaraty of 
users can satisfy their data requironents 
by querying: the shared database ushig 
nonprocedural dcdaratiohs of tbejfprm: 

SELECT what-i-want WHERE some- 

set-pf-oonditions-is-tnie • 

mitrnwufimmmwc iwieee 



A database administrator integrates the 
requirements of diverse usm. The shared 
database can be changed as long as the 
schoim is changed to reflect such changes. 
Cbncepts of database normalization help 
avoid redundancy of storage and anom- 
alies that are associated with updates of 
>edundantly,storedinfonnation. . 

The prindpal formal database mecha- 
' nism - to obtain selected data for an a^ 
/plication is a vi^ specification. A view on 
'a database coh^ of a query that defines 
> a suitably limited amount of data. A data- 
base adniinlstrator Is expected to use pre- 
defined yiewsasamanagementtoid. Hav- 
"iiig predefined views simplifies the. user's ' 
. access and caii also restrkt the user from 
infonnation that is to be protected. Weare 
^int^ested here bnly in the first objective, 
and not in the protection aqxcts assod- 
' ated with views. 

Views have seal formal treatment in re* 
lational databases, although subset defini- 
tions without structural tnuufonnattons 
are common in other commercial database 
systems. I will hoioe describe views from a 
relational point of view, without implying 
that a rdational implenwntation Is best for 
tlie underiying EIS itatabases. 

A View b defined in a rdational ntp^^ 
as a qutry over the.base relations, and 
pohaps also over other views; CurreDt lm- 
ptonehtatidhs do not" mateTialire views, 
but transform user operations on v^ws 
into opfcrations^ oyer the base data. The 
final result is olitained by interpreting the 
oombfaiation of view definition and iber 
query, using the description of the. 
database stored in the dmabase sdicnia. ' 

The view, Oke any relational query 
rc»ilt, is a rclatipn. However, even when 
tbe base database is fully normafized; say 
to Bbyce-Cbdd normal form, the view re- 
lation b, in general; only in first normal, 
fdnn. Views.are in thai sense already 
ddser to objects: rdated .data has been 
biooglu together. 
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The issue (hai views present data not in 
second or third normal form seems ig* 
norcd in database research, except for the 
update complications that result.'' I have 
: no evidence thai the unnormalized views ' 
.'ore uncomfortable to.a-'user expecting a 
..normalized relational representation. Ac- 
cepiahce of uhhorrnaliicd views - can be 
. iaken.as a partial validation of the accept- 
^.-ability of structures more suitable lorepre- 
' sen» objects than normalized tables. Some 
' current research is addressing unnormatiz- 
ed. relations independent from the view 
aspect. , 

Objects 

dbjeci-oriented programming Ian- 
.guages help to manage related data having 
a complex structure by combining them 
into objects. An object instance is a collec- 
tion of data elements and operations that 
is considered an entity. Objects arc typed, 
and the format and operationsof ah ob-~ 
jcci instance are inherited from the object 
prototype. : : , . *; = 

The prototype description for the object 
iype is predefmed and the object instances, 
are instantiated as rieeded for the^particu- 
,lar^pfoblem; The object" prototype then 
'provides a meia descriptionV similar to a 
schema provided for a database.' That de- 
scription is, however, fully accessible to 
the programmer, liiiefnally. an object can 
have an arbitrary. structure, and no user* . 
visible join 6iKtai|bns are required' to 
bring data elements iE>f one object instance 
together. 

The object concept covers a range of ap- 
proaches. One measure is the extent to 
which messages to external operation in- 
terfaces are used to provide access and 
manipulation f una ions. Objects may be 
active, -as in the Actors paradigm, or 
passive, as in CLU. or somewhere in be- 
tween, as in Simula or Smalltalk in terms 
of initialing actions. 

The use of objects permits the program- 
mer to manipulate data a: a higher level of 
absinuiton. Convincing arguments have 
been made for the use of objca-oricmed 
languages and some impressive demon- 
strations exist. Espectally attractive is the 
display capability associated with objects. 
Object concepts can of course be imple- 
mented using nonspecialized languages, 
for instance in LUp or Prolog. The tasks ui 
EIS seem to match objca-orientcil con- 
cepts well and many experiments have 
been conduaed. 

Objects and databases 

Let us assumed daubase is used for per- 
sistent yorage of shared objecu. A data- 
base query can obtain the infonnation for 



an object instance, and an object-oriented 
programming language can instantiate 
that object. An interface is needed, since 
neither can perform the task independent-, 
ly. A view can defme the information re- 

. quired for a collection of objects, buVthe 
data will not be arranged as expected for a 
collection of objects. Linkage to the object 
prototype and its operations is perfonhed : 
in the programming system. The program 
queries the database nonprocedurally 'to 
remain unaffected by database chan^ 

■ made to satisfy other users.-'; J . 

The query needed to instantiate an ob- ' 
ject may seem- quite complex to a pro- 
grammer. A relation is a set of tuples, and, 
from an idealized point otvtew; each iiiple i 
provides the data for soine object. How- 
ever, normalization often requires that in- 
formation concerning one object be. dts- . 
tribuied over multiple relations, and 
brought together as needed by join opera- 
tions. The base relations must contain all 
the data required to construct the: view* 
tuples; the composition knowledge is en- 
coded into the Select expressions used to 
construa the views. An ideal compbsttioii; 
of an object should. allow its. data to be' 
managed as a unit, btit unless non-flrst- 
normal form relations -^supporting re-, J 

. peating groups— are supported for viewsv , 
muliipte tuples are still required to repre- 

. sent one entity in a relational view. 
• Hence storage of objects is not easy in . 
databases, as indicated by the extensions 
proposed to Ingres for sudi tasks.^- A fur- 

- iher complexity is.that objects themselves 
may be< composed from niore primitive 
objects, in. hierarchical databases records 
may be assembled from lower level tuples, 
but in' relational databases the program- 
mer has to provide join specifications ex- 
ternally to assemble more comprehensive 
relations from basic relations. 

There is some hope that the formal tech- 
niques being developed for databases can 
permit the management of the informa- 
tion required to manage objects. Perfor- 
mance remains a bottleneck, and I uill 
consider this issue later with my proposal. 
The database community has to be careful 
not to promise too much too soon to the 
objectoriemcd folk. 

Sharing infonnation 
in objecto 

More serious are the problems I see in 
the management of shared infonnation 
within the object-oriented paradigm. I 
consider two problems: 

(1) The growth of objects that contain 
information for multiple design tasks. 

(2) The conflkt when object configura- 
tions differ for succesave design tasks. 
Let us first consider the simpler case. 



where multiple users deal with the 
configuration of objects. I will draw my 
examples from EIS, and consider t^at the 
objeas are components of a cirout.' 
Iri using an EfS tHe level of al^straction 
' ' for the objects chahges'duriiig the process 
:of design.'Ftrst the objects are simple logic - 
:elements and theprocess of design refines 
these objeins to circuit conipohents and, 
eventually, to simple gebirnetric elements 
/ projected from each layer of the chip. The 
: fuial objects will carry many data elements ' 
hot heeded at the hi^er levels. The sketch ' 
. in Figure 1 symbolizes how objects grow 
and lose their vitality.' 
/; As the design process moves from one 
' ;subtask to the next, successor objects are * 
. constructed out of earlier objects. Each 
'hew generation has' hew data fields 
appended.':.' 

Unfortunately, since design often re- 
quires cycles, old information cannot dis- 
app^. An unacceptable geometry may 
require a change at ;the circuit level, say 
adding an invertertrchaiige a polarity. If 
' design is iterative, then successive trans ' 
i ^f»;>rmaiions of objects must not lose infoi - 
' 'matioh. This means' thsu bbje<:ts suitable 
" for one task niust contain information rei- 
i eyant to all tasks that may be siiocessors, 
;.'ahhough ihiich iiriformatioh may beirrele* 
v^t to the t^k at hand. The ihformation' 
may be hidden within the object; but hitist 
.be passed on correctly, so it remains avail- 
able when needed. 

*.The objects become big; and hd loiiger 
have the qualities associated 'with the 
object-oriented paradigm. A solution to, 
this problem of overloaded objeas is to 
have super-objects, owned by an object 
czar. Objects for each user task type are 
created by projection from the super- 
object. Updating privileges must be well 
defined. 

This solution does not solvt the second 
class of problems, namely sharing objea 
information when the object configura- 
tion differs. Now, to create objects for a 
user task objects may have to be creat d 
from combinations of several and. per- 
haps, different objects or super-objects. 

I show in the next section an EIS exam- 
ple having components and nets connect- 
ing. These present differem configura- 
tions of the same information. In aircraft 
design the objects serve design tasks as 
aerodynamics, structures, power, fuel, 
control, etc., and it is obvious that their 
configuration Is quite different. Even in a 
simple commercial credit card operation 
there b the customer as an object for some 
tasks and the e^blishments are the ob- 
jects wanting to be paid in other tasks. 

Because of these problems, I present later 
a proposal that will not try to aore to ob- 
jects directly in persistent form. I prefer a 
new approach to satisfy the demands of 
database style sharing and object concepts. 
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; figure 1. Growth of objects . 
as Ihcy try to ntlify muttl- 
ptedo^tadn. V 



Looking at mme 
examples 

. . To dariiy the intioductipn I will take a 
simple device, a D-type latched flip-flop. 
At some level of abstraction it is an object; 
at a lower level it is composed of several 
gate objects of only three types: AND, 
INV. NOR. and contacts to the:«cternal' 
world. The, graphical representation :of 
' Figure 2 shows the component objects of >^ 
; the flip-flop at the gate level and the inter-- ^ 
' connection nets. The components are capr 
V italized and the nets have lowercase labels. ■ 
i ': A fully normalized database storing the a 
' information describing this ; circuit re- 
quires several relations. I show in Figure 3 
. the two library relations,- which describe 
the types of gates (Gates) and their connec> 
;tion points (Gate-connects). Many other 
values will be kept in siich aviibrary. The 
rufing part or key attributes of :each rela- 
tion are placed ahead of a separator 
syinbol:>. 

, Figure 4 presents a nonredundant repre- 
sentation for the speciflc circuit using two 
more relations, one for each gate instance 
and one giving the net connections for 
each gate. Other design-spedflc informa- 
tion can be kept within these relations. 

The rn>resentation of the design shown 
is quite complete, but also fairly unclear. I 
need to create views that place aU relevant 
data into coherent tuples. A view is needed 
to analyze the components and their loads; 
another view is needed to look at the nets; 
and other, views will be needed for timing 
analysis, heat dissipation, etc. 

In Figufe 5 1 extract two views. Cbm- 
poncntsView and Nets View for the data- 
base of . Figure 4, lising also the library 
idatioiis shown m Figure 3. The Cdm- 
ponentsView is intended to beappropriate 
for checking components and their 
sources and smks. It primarily aooesscs the 
Components relation, and joins with its 
tuptes data abom the connected compo- 
nents and from the libraries. 

The NetView b intended to genmte 
data on the int er c onn ection nets for an 
application doing checking. The primary 
relation for the NetView view is the 
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Connections relation, augmented with 
library information for the connected 
Gompcments. 

The number of objects in Componems- 
View is equal to thecardinality of the com- 
ponem rdation (l(9t but theaugmentatlon 
makes the lesuft much larger (30). The 
eight nets are represented in the primary 
relation and in the view by 20 tuples, one 
pa connected point ( o) or external con- 
tact (•). In both vkws I present the tuples 
in a lo^cal order. 

Thb view is stiQ awkward, since compo- 
nent entitles require multiple tuptes. A 



more reasonable i^esentation would de- 
lete redundancies and add implicit non- 
flrst-nonnal-form bindings by reanaqging 
columns according to the source relatkms. 
The Nor I component shown within Figure 
5 would then have a object data structure 
as shown in Figure 6. 1 add a cohunn N, 
which gives the number of coimected com- 
ponetits. The computation of N using SQL 
requlRS Group By and Count opoations. 

1 now describe in Figure 7 this structure 
m the object'Oriented extension of C, 
namely C++ (reference In C+ + 
stnictures have to be mappable at cominle 
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time, so arrays of dynamic extent cannot 
be embedded: Since it is permissible in 
C to hnve a dynamic array as the last 
ckmcnt of a ciAss by writing an a|q>ropri' 
ate constructor, it is possible to bring the 
CCpin array inboard. 

Views and objects 

Let us now reconsider the similarities 
between views and object concepts. Both 
ait intended to provide a better level of 
abstraction to the user, although the 
database user b seen to manipulate sets of 
objects in a nonprocedural notation while 
the objects are manipuUted procedurally 
and itcfativdy. 

The €oOe€tkm of tuples of a view is 
defmed by theqnery that genentcs the set, 
and described bif the relatioa<schcfna asso- 
ciated with the view query. The set of ob- 
jccu bdcfined by the user-initiated action 
of gEncntkm and described by the proto- 
type. Ol^ect-oriemed laogua^ m«y have 
a ForAO primiUve to rapidly genoate col- 
leciioosof objecu of fome type. 



The description of the relation has to be 
available lo the relational user, since no 
implied operations can be kept in the 
relation-schema. There are proposals to 
store objectHlefining procedures in rela- 
tional schemas, but these have not yet been 
tested.^ 

Both tuples and objects can be selected 
based on any of multiple criteria, and in- 
terrogated to yield dau for processing. 
View update may be severely resuicted 
because of ambiguities in base relation up- 
date. Object, update can be restricted by 
having only limited access functions, but 
otherwise no constraints are imposed on 
the programmer, although consistency 
problems can eaoOy arise among users 
sharing objects. 

Basic, of coufse. is the difference in per- 
sistence. Databases, and ha»e views over 
them, persist between program invoca- 
tions. Objecu must be expGdtly written to 
fDes to gam persstenoe. Related to per- 
nstence is the critical issue to be addressed, 
namdy the muhiplictty of views that can 
be derived fran a base relatioii. Figure 3 
showed a view of **oon]poitcnts** and a . 



view of 'iiets" derived from the relations 
of Figures 3 and 4. 



Hie proposed 
aichiteGtuial unit: . 
yiew-objeds 

I now propose tocombine the concepts 
of views and objects, as discussed above» 
into a single concept: view-objects. This 
proposal is mothrated by noting that sys- 
tems suitable for engineering information 
problem support require both shaiabflity 
and complex abstract units, i.e., both 
views and objects. I use the concept of 
views to geiierate a working set of objects 
corresponding to projections of the en-, 
tities described in the database.^ The 
generators may need to access multiple 
relations to reconstruct the entities hidden 
to the relational representation. Com- 
ponents of the architecture are 
. . (DasetofbaseidatfonBand, 
y (2) u set of view-objcct gracfaton. 
In a complete version of this approach 1 
also require the inverse function of (2), 
'^namely, 

.\ (3) a set of view-object decomposm' - 

' andaicfafven. 
The conceptual base rations serve as the 
persistent database for applications under 
this architecture. They contain all the data 
lieeded to create any specified object type. 
Conventional database technology should 
be adequate for development, but even- 
tually performance demands may drive 
users to specialized databases. I will con- 
sider the options for physical organiiation 
later. 

Concurrent access by long-lived trans- 
actions will require a capability to conve- 
niently access prior versions of the data. 
Where database management ^ems do 
not serve that need intrinsically, the 
database must be conQgured with addi- 
tional time-based attributes. As expoi- 
enoe is gained, this service will be included 
in spcriaiiFfd systems being built. 

The view-object generator b the new 
component in this architecture. It per- 
forms the foOowing steps: 

(a) The view-object generator extracts 
out of the base database data hi relatinnal 
form as needed— as is now done by a 
query coitespohding to a. view. A view 
tuple or set of vtew tu|te will contain pro- 
jected data corresponding to an obje^. A 
view relation wiD cover a selected set of 
objects. 

(b) The view-object generator assembles 
the data into a set of objects. The objects 
wiD be made avaOaUe to the program by 
attaching them to the pivdcfined object' 
prototype. 
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CREATE VIEW CbmpannuVicw (ID, Pin, IdC :) Type, N, lO, lOO 














AS SELECT CM, CPin, CCJd. CM.Type, T.No-pms, CIO. GC.IO 














FROM Connections C CC. Omiponats Gate-connects G GC, Gues T, 












WHERECld = 


CM.IdANDC.Net 


CC.Nct AND C.T^ » T.Gase4yDe 












ANDC.TVpe = 


G. Gate^ype AND CCTVpe » GC.Gaie4ype; 












CREATE VIEW NeuView (Net. Dev. Pd:) lOd) 
















AS SELECT C4ict. Cld, CPin. GC.IO 
















FROM Cnmecti 


om C..Goniponcnts CM, Gate^onnecis G CC. Gates T. 
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= T.Gate-type: . 
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The view-object gooerator needs infor« 
niation other than the data, Le., iosowl- 
edge to perf oim its f uncthms: . 

(al) The quoy poitioD identifies the 
basedata. 

(a2) The .qwrifjcatfon of the primaiy 
icbtton idcmifies the object^cntities. 

(a3) The olject prototype specifos the 
stnictiireand linkages of the data doncnts 
withm an object* and the aooes fiuncttons 
fortheobyecL 
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Initially the view-cbjea generators will 
be Implemented as code, closely following 
the translation programs in use now to 
convm persistent storage representations 
of engineering data files into representa- 
tions sit&able for specific tools. For ex- 
periments a relational dalalwwe can be 
used for stmtige of the base data, but ex* 
pect that ongbingdevckiinnenufaiEIS win 
provide ^ystenns with more apprcvriate 
functionality and perfonranoe. 



enum to {IN. OUT. INOUT|: 

ctass Cpin; 
dass CCpin; 

class ComponcntsVicw 

I 

char Id [9]; 
char Type (6); 

short P: // Componem |rin oouni 
Cpin* Pin; 

I; 

class Qiin 

I 

k> lO; 

short Q: // Connected component 

count 
CCpin* C. 

I; 

dass CCpin 

I 

diar* IdC; 
lo IOC: 

I; 



flSBre 7. C'f'f datastradnre for Cooh 



FIgnre 6« Rednnd datastrecCnre for a View Object* 
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The soa] i> lo ever,(uaily provide oon- 
pfO\vduraJ access for objtp,! -oriented ap- 
prczjchts as vvelL By formalizing* ?iie 
' ^enHintics o\ th.? objvNris rcquired hy the 
lools. and inicfj)re(ing I he objccc lypc 
'dffscripiion. ! believe {he view -object 
ii5!je:a?o:^ may be auton:a.'':d. The pro- 
gramiFief ihen oru'v prondcs jiiie object ' 
lypr cU-cl;iraiio« and the -V.'h-r^' vlau&e 
defining the desired \ei o« w";C'CS 

. instances. ■ .* 

\Vi»h inc.-eastd sjcragv of daia seman- ' 
lies' in e.\! ended scheinas oae may advance* 
fiireher, With Mruciural or dependency in- 
{"onTiaiion abou; the base rclatiorxs", autc- 

' maitc generation of the iniernal 5irucrurc o.' 
ah object type may become rcaiible. Since 
access to ?hc objects by i lie look is siiil pro- 
cedurai, ihe performance bcneHts o! 
auTomaled objeci gcncraiion . would bt 
minor. The major benefii is tii the control uf 
access, and constsicncy ihai may be gamed. 

I.ustification " 

• • • • • . . 

I am proposing a major exiensiori lo - 
daiabasc and objeci -orieiued/cpncepis. 
wHh the iritcni !o obtain the joint bertcfits 
that each approach provides separately 
loday. The effon must jusiiftcd'ty these 
■beiiefiis. - • > 

SharaM? scci^s lo objects. The pro- 
posed architecture siippons procedural 
access to objects, as expected by objeci. ' 
oriented programming systems. Access io 
the base data is automatic, and nonpro- 
cedural . This permits base data to be effec- 
tively shared, since no single application or 
combination of .applications imposes a 
structure on the base relations. 

Cifowtb off she systeiR. New objeci types 
can be defined by adding n«w view-object 
generators. As is expected In databases, 
new data instances* types, and entire rela- 
tions can be added without affecting other 
users' programs. Data can be reorganized 
without changing the object generator 
code since only the views will be involved. 
Such flexibility is essential for growth and 
multiuser access. 

Support ffor a wide vaiiety off represeo* 
l&Uoas. When simple tabular results are to 
be obtained from the database, a view- 
objea generator can easily generate tables 
for direct tnsixaion and manipulation. A 
graphics objea-generator can project the 
attributes needed for visual display. 



b*>ii!eneck whtn delivering data to pro- 
gran)s. A common method for reiaiionaJ 
sy.^!ems is to accept a query that specifies a 

/ ao*, then require repeated invocation!. 
;hat debvei only single vahies or records at a 
time. This access mode.* because of con ven- 
lional programming techniques, h siea/ly 

, insdequaic: ; i - 

The data'fiom the daifiba.{e& is io.be in- ' 

' veried into scisof objeasat a time.- For ihe 
object -oriented programmer such a set i.5 
best defined as a super-object. A program . 
typically cannot proceed until the. .set is 
complete. The object generatoni need only 
be invoked once for all the data needed to 
compose a super-r.bject ; An effect iv'e 
vicuH>bjei:i generator hence needs an in- 
terface at a deeper level into the existing 
relational functions. 

L'pda<mg from objeci!^. The programs 
can freely update the contents of the ob- 
jecis. Some applications require that these 
changes be made persistent and hence be^ • 
moved Mom its obie«:t representation to -» ^ 
the base database. • */. -■ * , 

• To achieve update 1 envisage a third ar-* ; * ' 
chitectural coni^ncnt, the view-update 
generator. This component can be invoked 
at commit-ti.nie; ivhen resuhs affecting the ; ^ 
objects are to be made persistent. I en- i. 
visage thai, such a process will only .update 
from objects that have changed, and only 
replace values that were changed. ' * 

Where views have been constructed 
u.sihg joins, aggregation' operators; and -^^" 
the like, automatic view update can beam- ■ ' ' 
biguous. Restrictions on object update are' ' 
one solution. However, as shown by 
Keller,** such ambiguities can be enumer- 
ated and a choice can be made when the 
vicw-updaie is generated. The view update 
generator can also lake advantage of the 
semantic knowledge available to an ad- 
vanced view-object generator. An impor- 
tant source of knowledge constraining up- 
dates is authorization information. 



bae« To achieve this goal new daiaoase in* 
tcrfaoes must be devdoped chat make the 
benefhsofcheset-oriRiteddatabase retriev* 
al ooBoepis available to progiammiag Ian- 
guages. Cuncnt database tnterfaoescreatea 



Cost trade^sffs 

What costs and benefits will this archi- 
tecture provide other than what I see as its 
structural advantage? I will now review 
areas where performance may be gained 
versus one of the two underlying ap- 
proaches^-database use or object- 
oriented programming— alone. 

Se(«bs9al data access. A single invoca- 
tion of a viewobjeci generator will instan- 
tiate all specified objects. The overhead of 
programmed access to relations, typically 
requiring an initial Call giving the query 
and then itmted CaQs to obtain the result 
piece b;: piece, is avoided. Also, no sc- 
queioce of object instance-generating 
CaDs, as seen in object-oriented program- 
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ming« is needed. Of course, one invocation 
of I he object generator will be a major 
operation, but only one call should be* 
needed per object type. 

The object genc-rator may abo perform 
the'soolled macro-generator function, ' 
where instances of design, objects * are 
^generated based ^ on a general prototype . 

* and parameters. The source of such infor- 
mation is a library of cell descriptions, per- • 
milting, say, the generation of a series of 

♦ cells niaking up a register,- 

: The view-object generator will be more 
complex than either a database retrieval* 
alone or. an object proioiype. It will pro- 

: vide a very clear definition of the mapping 
from base data to objects and do so in a 

localized manner. A partial example w£s 

: given, using the SQL approach to describe 
the view in Figure 5 and then using C + + 
to define the storage structure for the ob- 
jects in Figure 7. 

Binding of retrieved data. The ability of 
the view-object generator to bind the ob,t. 
jea will pay off . in processing time. No 
joins arc needed at execution to biiid rela-; : 
tional tuples, and no search operations are 

..needed to assemble tuples belonging to the. 

< same; object. Since the required informa- 
tion exists at view. generation time, no- 
search cost is expended. The only require- 
ment is that the object's internal data struc- 
ture permit retention of the informaiiori. 

Task aUocatton that matches hardware 
system components. Implicit, but not 
essential, to my proposal are the comple- 
mentary concepts of database servers and 
design workstations. They will be linked 
by a powerful, but often still, bandwidth- 
limhed communication network. In such 
an architecture I expect that most of the 
retrieval and restriction operations will be 
carried out on the machine serving the 
database and the objea generation and 
use will occur in the workstation. 



Optimization in the file server. Ttie file 
server can select optimum retrieval strate- 
gies and reduce the data volume needed to 
convey the information. Keeping data in 
sorted order and removing redundant 
fields as shown in Figure 6 is straight- 
forward and effeaive. All operations are 
specified nonprocedurally and can be ar- 
ranged and interleaved as needed to han- 
dle requests from the users. Concurrency 
control and version management are tasks 
best handled in the file server. 

Conunonlcatloii mlnimizailoii. The 
data volume is reduced in the file server. 
Conununication bandwidth between server 
and workstation can be used fiilly for in- 
fonnation, rather than for data to be ig- 
nored in the workstation. 
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Higb perfonnance on workstations. The 
workstation only needs to assemble the in- 
formation obtained into the desired object 
conflguration. It is desirable that aO ob- 
jects for an application task can be placed 
into the real memory of the working pro- 
cessor.^ The objects now do not contain, 
data fields irrelevant to the process at> 
hand. Since these working objeas are now 
compact, the probability that they will all. 
fit into a modem workstation is increased.- 
Virtual memory management can be in- 
voked if needed, but the capacities of 
modern machines are such that there 
should be adequate memory space for 
working storage of the required objects. 
However, I can envisage several techniques, 
to exploit having the data independence* 
' provided by view generators to improve 
locality for virtual memory management. , 

Physical oi^aKiization 
of the database 

• {Performa.nce issues are considered 
critical in EISs, andexpenmenis with rela-' 
lional databases have not given me confi- 
dence that adequate perfonnance is easy 
to obtain. Performance will furthermore- 
be impacted by the extensiop<5. such as 
versipn support, that are needed in the ' 
engineering environment.' Many of these 
extensions will also be useful for broader' 



objeaives. so that there is a motivation to 
share the development and maintenance 
costs of relational databasie systems 
extensions. 

Objects are seen as a means to solve the' 
performance problemr' because data is* 
/ ' bound in a user-sensible maimer. I believe' 
>' ;that such binding can indeed be significant 
fin workstaitohs,' although my own experi- 
^ ments have not given- proof of that as- ' 
sumption when exteraal'storpTe'lstisied.^ 

* ^.There are obviously many my* e factors to 

* be considered- simultaiieou sly when 
building comprehensive systems; butstpr-' 
ing data in relational tables is often seen as 
a critical issue. * * . ' • 

; The fiilly normalized model of the rep- • 
resentation has as its objective the minimi- 
zation of redundancy and the avoidance ■ 
-of a number of anomalies that can occur. 
It also supports a ver>- simple storage 
structure, as seen in our example, thai can 
lead to a large number of relations. 
Retrieval from such an prgahizatibn.'will ^ 
require a large number of joins, as seen in 
the example leading to Figure 5, 
' Updates seem to require less work in u 
^•relational database than in bur proposal.-. 
- 'However, when the database has to obey . 
interrelatiohal constraints; expensive joins 

* mufit also be executed when' the data are 
' updated. For instance, it. is necessary to ^ 
; ensure that the components exist and that 

the connectrans are valid -when a net con- 
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nccJion is to be cltangsd. 
' There is. of course, no requirement for 
ihe physical siorage struciure to mimic 
!iicrally ihe logical rclaiional siruciure. 
Specifically, information from muhiptc 
l uple^i may be stored in one record . Denor- 
maiizaiion has been formally considered, 
bat is not supported by current DBMSs/lt 
iv commonly employed in practical rela* 
lidn&l databases. Preserving correctness in 
-a denormaiizod database often requires' 
'additional transformation and care: 
records may have repeated field? and at' 
other times some fields may be rephcaied 
in mutitple records. Sometimes here work 

' n required as well: dependent tuples. a< 
connect toil points for a component', ivil) 
aufomaiically be deleted if they were im- 
plemented as a repeating group. 1 cxpeci to 
profit here from ongoing research on non- 
first-norniat-form databases. 

In my architecture, where I expect thai 
the object generator is the primary means 
for accessing data, complexity issues dis- 

. cou raging use of a iton-nomiali/ed storage 
struciure are moot. Tne object generators 

V can he adjusted, probably eventually auio- 
inaiically^ to any storage structure choseii! 
It is likely that the most efficient storage 

^siriiciure will be similar to the dominant 

'^object structure. 

' ' With such an organti!aiidn I have pro- 
vided the two primary objectives favoring 
the concept of object-oriented progranis 
for computer-aided design: 

( 1 ) The concept of a viewK)bjeci pro- 
vidr» the desired clean and compact user 
interface. 

(2) The flexibility of the storage struc- 
ture can provide the locality needed to 
achieve high performance in source data 
access. 

I can now provide these objectives for 
multiple users, and share selected infor- 
mation in a controlled fashion. I gain 
greatly from the neiiibility obtained by 
interposing the objed generator operating 
on a persistent base storage structure. 1 am 
no longer bound to an optimal data stor- 
age structure bound to an optimal object 
format. It is tikdy that in any design proj- 
ect the data retrieval loads will change over 
time. The object types that dominate use 
during initial design phases are not likely 
to be the objea i>'pes used during the 
maintenance phase of the designed de- 
vices. A physical storage reorganization is 
now possible, as long as the view-object 
generators ore adjusted correspondingly. 

Replication, the primary tool to improve 
performance, can be utilized as well. A 
htgh-demand subset of the database can be 
replicaicd and made available in a perfor- 
mance-effeaive manner to the object 
generators. Object update functions can 
use primary oopy token concepts to update 
aQ cofte ctMisistemly and syntchronously. 



argue that dtn-ct siorage of objects, 
to make them persistent, is not ap-' 
propriate for large, multi-user" 
engineering informaiion s>'stems. I pro- 
pose storage- using retktional concepts. ; 
and an interface that generates objects. To 
test the validity of the concept, initial ver- 
sions of the inienace may be coded direct- * 
ly. In the longer range I look toward 
krjowlcdge^riven transformations. 

Generation of objijcts frorh base data 
brings the ad^'^ntages of sharing persiiteht • 
information to an object -orieiited pro- ' 
gram, h also provides a better interface 
from programs so* databases, recognizing 
that'access by programs, large or <»»*2H. 
vnW remain essential for data analysis and . 
complex iransaaions. 

The separation of siorage and working 
representation will also simplify ihcdevc!-' ' 
opmcnt of nev approaches to engineering 
design.'^ The object generator can be 
viewed as a system component utilizing 
knowledge to select and aggregate data for • 
the informaiion objectives. :* ; * 
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